New cheatcodes (draft) #643
Conversation
…edusa into add-init-fn-per-fuzz-run
- getDeployedCode - assertTrue / assertFalse - assume - expectEmit (NOOP for now) - expectRevert (WIP) - assertEq (and variant)
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // getCode: Retrieves the runtime bytecode for a contract | ||
| contract.addMethod("getDeployedCode", abi.Arguments{{Type: typeString}}, abi.Arguments{}, | ||
| func(tracer *cheatCodeTracer, inputs []any) ([]any, *cheatCodeRawReturnData) { | ||
|
|
||
| contractPath := inputs[0].(string) |
There was a problem hiding this comment.
The getDeployedCode cheatcode is registered with zero output arguments (abi.Arguments{}) but the handler returns []any{bytecode}. CheatCodeContract.Run ABI‑packs return values according to the declared outputs, so returning a value with no outputs causes packing to fail and the call always reverts. As written this cheatcode can never succeed. It should expose a bytes output or avoid returning data.
Useful? React with 👍 / 👎.
| return string(l.([]byte)) == string(r.([]byte)) | ||
| case abi.FixedBytesTy: | ||
| lBytes := l.([32]byte) | ||
| rBytes := r.([32]byte) | ||
| return string(lBytes[:]) == string(rBytes[:]) |
There was a problem hiding this comment.
The abi.FixedBytesTy branch in assertEqGenerator casts both inputs to [32]byte. When the cheatcode is invoked for bytes4 (registered above), the values are [4]byte, so the type assertion panics with interface conversion: [4]uint8 is not [32]uint8. Any assertEq on non‑32‑byte fixed arrays will therefore crash the cheatcode. Use the ABI type’s Size to cast to the correct array or compare slices instead.
Useful? React with 👍 / 👎.
| stack := scope.StackData() | ||
| index := len(stack) - 1 | ||
| return_value := stack[index] | ||
| if return_value.Eq(uint256.NewInt(0)) { | ||
| stack[index] = *uint256.NewInt(1) | ||
| } else { | ||
|
|
||
| if !return_value.Eq(uint256.NewInt(1)) { |
There was a problem hiding this comment.
When an expectRevert marker is detected, OnOpcode fetches the stack via scope.StackData() and assigns to stack[index]. StackData() returns a copy of the stack, so the write does not affect the actual EVM stack and the success flag pushed by CALL remains unchanged. Consequently the cheatcode never flips 0↔1 and cannot enforce expected reverts. The code needs to mutate the real stack (e.g. through the stack object) instead of a copy.
Useful? React with 👍 / 👎.
3 participants
This PR is a WIP to add new cheatcode to medusa. The PR is not ready yet, but I am sharing it in case anyone has time to provide some feedback.
It's built on top of #618, so the code outside of chain/cheat_code_tracer.go / chain/standard_cheat_code_contract.go is not relevant to the PR.
Once I have stabilized everything, I will open individual PR to make the review easier + add the relevant documentation.
Open questions:
getDeployedCodewould benefit from some logging to let the user knows if the targeted contract was not deployed, but I am not sure how to log this properlyexpectRevertis the right approach. The cheatcode is a bit tricky given it's logic, so I had to modify theOnOpcodehook (cheat_code_tracer.go). It works by havingexpectRevertadding a placeholder variable, that basically means "once you execute the first opcode after returning from the targeted call, invert the value on the stack". If you have a cleaner idea on how to handle this one, let me knowThe new cheatcodes: